%****************************************************************************%
%* DIET User's Manual deploying chapter file                                *%
%*                                                                          *%
%*  Author(s):                                                              *%
%*    - Holly DAIL (Holly.Dail@ens-lyon.fr)                                 *%
%*    - Raphael BOLZE (Raphael.Bolze@ens-lyon.fr)                           *%
%*    - Eddy CARON (Eddy Caron@ens-lyon.fr)                                 *%
%*    - Philippe COMBES (Philippe.Combes@ens-lyon.fr)                       *%
%*                                                                          *%
%* $LICENSE$                                                                *%
%****************************************************************************%
%* $Id: deploy.tex,v 1.21 2008/07/16 23:02:48 ecaron Exp $
%* $Log: deploy.tex,v $
%* Revision 1.21  2008/07/16 23:02:48  ecaron
%* Fixe the problem with too long list of hosts
%*
%* Revision 1.20  2008/03/04 16:12:37  bdepardo
%* Added a link to the file examples/commented.xml for GoDIET.
%*
%* Revision 1.19  2006/11/29 16:55:49  dloureir
%* minor corrections
%*
%* Revision 1.18  2006/05/12 12:12:32  sdahan
%* Add some documentation about multi-MA
%*
%* Bug fix:
%*  - segfault when the neighbours configuration line was empty
%*  - deadlock when a MA create a link on itself
%*
%* Revision 1.17  2005/07/13 07:56:15  hdail
%* Corrected error in xml example and added console instructions to GoDIET section.
%*
%* Revision 1.16  2005/07/12 21:44:28  hdail
%* - Correcting small problems throughout
%* - Modified deployment chapter to have a real section for deploying via GoDIET
%* - Adding short xml example without the comments to make a figure in GoDIET
%*   section.
%*
%* Revision 1.15  2005/06/28 15:53:02  hdail
%* Completed corrections for config file examples and text explaining launch of
%* each component.
%*
%* Revision 1.14  2005/06/28 13:57:55  hdail
%* Described GoDIET and updating section on launching by hand.
%*
%* Revision 1.13  2005/06/24 14:27:07  hdail
%* Correcting english problems & updating descriptions that are no longer true.
%*
%* Revision 1.12  2005/06/14 08:26:32  ecaron
%* Deployment section should introduce GoDIET (Fixme for Holly)
%*
%* Revision 1.11  2005/05/29 13:51:22  ycaniou
%* Moved the section concerning FAST from description to a new chapter about FAST
%* and performances prediction.
%* Moved the section about convertors in the FAST chapter.
%* Modified the small introduction in chapter 1.
%* The rest of the changes are purely in the format of .tex files.
%*
%* Revision 1.10  2004/10/25 08:59:56  sdahan
%* add the multi-MA documentation
%*
%* Revision 1.9  2004/09/28 07:03:39  rbolze
%* remove useAsyncAPI parameter
%*
%* Revision 1.8  2004/07/12 08:33:58  rbolze
%* explain how to copy cfgs file in install_dir/etc directory and correct my english
%****************************************************************************%

\chapter{Deploying a DIET platform}
\label{ch:deploying}

Deployment is the process of launching a DIET platform including agents
and servers.  For DIET, this process includes writing configuration
files for each element and launching the elements in the correct
hierarchical order. There are three primary ways to deploy DIET.

Launching \textbf{by hand} is a reasonable way to deploy DIET for
small-scale testing and verification. This chapter explains the 
necessary services, how to write DIET configuration files, and in
what order DIET elements should be launched.  See
Section~\ref{sec:deployBasics} for details.

\textbf{GoDIET} is a Java-based tool for automatic DIET deployment
that manages configuration file creation, staging of files, launch
of elements, monitoring and reporting on launch success, and process
cleanup when the DIET deployment is no longer needed.   See 
Section~\ref{sec:deployGoDIET} for details.

\textbf{Writing your own scripts} is a surprisingly popular
approach.  This approach often looks easy initially, but can
sometimes take much, much longer than you predict as there are many
complexities to manage.  Learn GoDIET -- it will save you time!



\section{Deployment basics}
\label{sec:deployBasics}

%====[ Deploying CORBA services ]==============================================
\subsection{Using CORBA} 
\label{sec:CORBA_services}

CORBA is used for all communications in DIET and for communications
between DIET and accessory services such as LogService, VizDIET, and
GoDIET.  This section gives basic information on how to use DIET
with CORBA.  Please refer to the documentation of your ORB if you
need more details.

\subsubsection{The naming service}

DIET uses a standard CORBA naming service for translating an
user-friendly string-based name for an object into an Interoperable
Object Reference (IOR) that is a globally unique identifier
incorporating the host and port where the object can be contacted.
The naming service in omniORB is called \texttt{omniNames} and it
must be launched before any other DIET entities.  DIET entities can
then locate each other using only a string-based name and the
$<$host:port$>$ of the name server.

To launch the omniORB name server, first check that the path of the omniORB
libraries is in your environment variable \texttt{LD\_LIBRARY\_PATH}, then
specify the log directory, through the environment variable
\texttt{OMNINAMES\_LOGDIR} (or, with \textbf{omniORB 4}, at compile time,
through the \texttt{--with-omniNames-logdir} option of the omniORB configure
script). If there are no log files in this directory,
\texttt{omniNames} needs to be intialized. It can be launched as
follows: 
{\footnotesize
\begin{verbatim}
~ > omniNames -start

Tue Jun 28 15:56:50 2005:

Starting omniNames for the first time.
Wrote initial log file.
Read log file successfully.
Root context is IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e61
6d696e67436f6e746578744578743a312e300000010000000000000060000000010102000d0000003134
302e37372e31332e34390000f90a0b0000004e616d655365727669636500020000000000000008000000
0100000000545441010000001c0000000100000001000100010000000100010509010100010000000901
0100
Checkpointing Phase 1: Prepare.
Checkpointing Phase 2: Commit.
Checkpointing completed.
\end{verbatim}
}

This sets an omniORB name server which listens for client connections
on the default port 2809. If omniNames has already been launched once,
\emph{ie} there are already some log files in the log directory, using
the \texttt{-start} option causes an error. The port is actually read
from old log files: {\footnotesize
\begin{verbatim}
~ > omniNames -start

Tue Jun 28 15:57:39 2005:

Error: log file '/tmp/omninames-toto.log' exists.  Can't use -start option.

~ > omniNames  

Tue Jun 28 15:58:08 2005:

Read log file successfully.
Root context is IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e61
6d696e67436f6e746578744578743a312e300000010000000000000060000000010102000d0000003134
302e37372e31332e34390000f90a0b0000004e616d655365727669636500020000000000000008000000
0100000000545441010000001c0000000100000001000100010000000100010509010100010000000901
Checkpointing Phase 1: Prepare.
Checkpointing Phase 2: Commit.
Checkpointing completed.
\end{verbatim}
}

\subsubsection{CORBA usage for DIET}

Every DIET entity must connect to the CORBA name server:
it is the way services discover each others. The reference to the
omniORB name server is written in a CORBA configuration file, whose path
is given to omniORB through the environment variable
\texttt{OMNIORB\_CONFIG} (or, with \textbf{omniORB 4}, at compile
time, through the configure script option:
\texttt{--with-omniORB-config} ). An example of such a
configuration file is given in the directory
\texttt{src/examples/cfgs} of the DIET source tree and installed in
\texttt{$<$install\_dir$>$/etc}. The lines concerning the name server
in the omniORB configuration file are built as follows:
\begin{description}
 \item{omniORB 3:}
{\footnotesize
\begin{verbatim}
ORBInitialHost <name server hostname>
ORBInitialPort <name server port>
\end{verbatim}
}
 \item{omniORB 4:}
{\footnotesize
\begin{verbatim}
InitRef = NameService=corbaname::<name server hostname>:<name server
port>
\end{verbatim}
} 
\end{description}
The name server port is the port given as an argument to the
\texttt{-start} option of \texttt{omniNames}.  You also need to update
your \texttt{LD\_LIBRARY\_PATH} to point to
\texttt{$<$install\_dir$>$/lib}.  So your \texttt{LD\_LIBRARY\_PATH}
environment variable should now be :\\ \texttt{LD\_LIBRARY\_PATH$=
<$omniORB\_home$>$/lib:$<$install\_dir$>$/lib}.

\textbf{NB1:} In order to avoid name collision, every agent must be 
assigned a different name in the name server; since they don't have any 
children, SeDs do not need names assigned to them and they don't register with
the name server.

\textbf{NB2:} Each DIET hierarchy can use a different name server, or multiple 
hierarchies can share one name server (assuming all agents are assigned 
unique names).  In a multi-MA environment, in order for multiple hierarchies
to be able to cooperate it is necessary that they all share the same
name server.

%====[ DIET configuration file ]===============================================
\subsection{DIET configuration file}
\label{sec:diet_config_files}

A configuration file is needed to launch a DIET entity. Some fully
commented examples of such configuration files are given in the
directory \texttt{src/examples/cfgs} of the DIET source files and
installed in \texttt{$<$install\_dir$>$/etc} \footnote{if there isn't
\texttt{$<$install\_dir$>$/etc} directory, please configure DIET with
\texttt{--enable-examples} and/or run \texttt{make install} command in
\texttt{src/examples} directory.}. Please note that:
\begin{itemize}
\item comments start with '\#' and finish at the end of the current
  line,
\item meaningful lines have the format: \texttt{keyword = value},
  following the format of configuration files for omniORB 4,
\item for options that accept 0 or 1, 0 means no and 1 means yes, and
\item keywords are case sensitive.
\end{itemize}

\subsubsection{Tracing API}

\noindent
\texttt{traceLevel} \ \ \emph{default}\texttt{ = 1}\\
This option controls debugging trace output. The following levels are defined:

\begin{center}
 \footnotesize
 \begin{tabular}{p{.1\linewidth}p{.8\linewidth}}
  level $=$ 0  & Print only errors\\
  level $<$ 5  & Print errors and messages for the main steps (such as ``Got a
  request'') - default\\
  level $<$ 10 & Print errors and messages for all steps\\
  level $=$ 10 & Print errors, all steps, and some important structures (such
  as the list of offered services)\\
  level $>$ 10 & Print all DIET messages AND omniORB messages corresponding to
  an omniORB traceLevel of (level~-~10)
 \end{tabular}
\end{center}


\subsubsection{Client parameters}

\noindent
\texttt{MAName} \ \ \emph{default}\texttt{ = }\emph{none}\\ This is a
\textbf{mandatory} parameter that specifies the name of the Master
Agent to connect to. The MA must have registered with this same name
to the CORBA name server.


\subsubsection{Agent parameters}

\noindent
\texttt{agentType} \ \ \emph{default}\texttt{ = }\emph{none}\\
As DIET offers only one executable for both types of agent, it is
\textbf{mandatory} to specify which kind of agent must be launched. Two values
are available: \texttt{DIET\_MASTER\_AGENT} and \texttt{DIET\_LOCAL\_AGENT}.
They have aliases, respectively \texttt{MA} and \texttt{LA}.
\\

\noindent
\texttt{name} \ \ \emph{default}\texttt{ = }\emph{none}\\ This is a
\textbf{mandatory} parameter that specifies the name with which the
agent will register to the CORBA name server.


\subsubsection{LA and SeD parameters}

\noindent
\texttt{parentName} \ \ \emph{default}\texttt{ = }\emph{none}\\ This
is a \textbf{mandatory} parameter for Local Agents and SeDs, but 
not for the MA.  It indicates the name of the parent (an LA or the
MA) to register to.

\subsubsection{Endpoint Options}

\noindent
\texttt{dietPort} \ \ \emph{default} \texttt{ = none }\\ This
option specifies the listening port of an agent or SeD. If not
specified, the ORB gets a port from the system. This option is very
useful when a machine is behind a firewall. By default this option
is disabled.\\

\noindent
\texttt{dietHostname} \ \ \emph{default} \texttt{ = none }\\
The IP address or hostname at which the entitity can be contacted
from other machines. If not specified, let the
ORB get the hostname from the system; by default, omniORB takes the
first registered network interface, which is not always accessible
from the exterior.  This option is very useful in a variety of
complicated networking environments such as when multiple interfaces
exist or when there is no DNS.

\subsubsection{LogService options}

\noindent
\texttt{useLogService} \ \ \emph{default}\texttt{ = 0}\\ This
activates the connection to LogService. 
If
this option is set to 1 then the LogCentral must be started before any
DIET entities. Agents and SeDs will connect to LogCentral to deliver
their monitoring information and they will refuse to start if they
cannot establish this connection. See Section~\ref{sec:LogService} 
to learn more about LogService.\\

\noindent
\texttt{lsOutbuffersize} \ \ \emph{default}\texttt{ = 0}\\
\noindent
\texttt{lsFlushinterval} \ \ \emph{default}\texttt{ = 10000}\\ DIETs
LogService connection can buffer outgoing messages and send them
asynchronously. This can decrease the network load when
several messages are sent at one time. It can also be used to decouple
the generation and the transfer of messages.  The buffer is specified
by it's size (\texttt{lsOutbuffersize}, number of messages) and the
time it is regularly flushed (\texttt{lsFlushinterval},
nanoseconds). It is recommended not to change the default parameters
if you do not encounter problems. The buffer options will be ignored
if \texttt{useLogService} is set to 0.


\subsubsection{FAST options}

\noindent
Currently, FAST is only used at the SeD-level, so these parameters
will only have an effect in SeD configuration files.\\

\noindent
\texttt{fastUse} \ \ \emph{default}\texttt{ = 0}\\ This option
activates the requests to FAST. It is ignored if DIET was compiled
without FAST, and defaults to 0 otherwise. \\

The following options are ignored if DIET was compiled without FAST or if
\texttt{fastUse} is set to 0.

\noindent
\textbf{LDAP options}

\noindent
\texttt{ldapUse} \ \ \emph{default}\texttt{ = 0} \\
This option activates the use of LDAP in FAST requests.  Only SeDs
need to connect to the LDAP so the option is ignored at the agent-level. \\

The following two options are ignored if \texttt{ldapUse} is set to 0.
\\

\noindent
\texttt{ldapBase} \ \ \emph{default}\texttt{ = }\emph{none}\\ Specify
the \texttt{host:port} address of the LDAP base where FAST gets the
results of its benchmarks.  \\

\noindent
\texttt{ldapMask} \ \ \emph{default}\texttt{ = }\emph{none}\\ Specify
the mask used for requests to the LDAP base. It must match the one
given in the \texttt{.ldif} file of the server that was added to the
base.


\noindent
\textbf{NWS options}

\noindent
\texttt{nwsUse} \ \ \emph{default}\texttt{ = 0}\\ This option
activates the use of NWS in FAST requests. If 0, FAST will use an
internal sensor for the performance of the machine, but will not be
able to evaluate communication times.  \\

The following option is ignored if \texttt{nwsUse} is set to 0.
\\

\noindent
\texttt{nwsNameserver} \ \ \emph{default}\texttt{ = }\emph{none}\\
Specify the \texttt{host:port} address of the NWS name server.
\\

\noindent
\textbf{Multi-MA options}

\label{sec:multimaconfig}

To federate resources, each MA tries periodically to contact other
MAs. These options define how the MA connects to the others.\\

\noindent
\texttt{neighbours} \ \ \emph{default}\texttt{ = empty list \{\}} \\
List of known MAs separated by commas. The MA will try to connect
itself to the MAs named in this list. Each MA is described by the name
of its host followed by its bind service port number (see
\texttt{bindServicePort}). For example \texttt{host1.domain.com:500},
\texttt{host4.domain.com:500}, \texttt{host.domainB.net:2001} is a
valid three MAs list. By default, an empty list is set into
\texttt{neighbours}.\\

\noindent
\texttt{maximumNeighbours} \ \ \emph{default}\texttt{ = 10}\\ This is the
maximum number of other MAs that can be connected to the current MA.  If
another MA wants to connect and the current number of connected MAs is equal to
\texttt{maximumNeighbours}, the request is rejected.\\

\noindent
\texttt{minimumNeighbours} \ \ \emph{default}\texttt{ = 2}\\ This is
the minimum number of MAs that should be connected to the MA. If the
current number of connected MA is lower than
\texttt{minimumNeighbours}, the MA tries to connect to other MAs.\\

\noindent
\texttt{updateLinkPeriod} \ \ \emph{default}\texttt{ = 300}\\ The MA
checks if the connected MAs are alive every \texttt{updateLinkPeriod}
seconds.\\

\noindent
\texttt{bindServicePort} \ \ \emph{default}\texttt{ = none}\\ 
The MAs need to use a specific port to be able to federate themselves. This
port is only used for initializing connections between MAs. If this
parameter is not set, the MA will not accept incoming connection.\\



%====[ Example ]=========================================
\subsection{Example}
\label{sec:deploy_ex}

As shown in Section \ref{init}, the hierarchy is built from top to
bottom: children register to their parent.

Here is an example of a complete platform deployment. Let us assume
that:

\begin{itemize}
\item DIET was compiled with FAST on all machines used,
\item the LDAP server is launched on the machine \texttt{ldaphost} and listens
  on the port 9000,
\item the NWS name server is launched on the machine \texttt{nwshost} and
  listens on the port 9001,
\item the NWS forecaster is launched on the machine \texttt{nwshost} and
  listens on the port 9002,
\item the NWS sensors are launched on every machine we use.
\end{itemize}


\subsubsection{Launching the MA}

For such a platform, the MA configuration file could be:
\tt
\begin{center}
 \footnotesize
 \begin{tabular}{lcll}
  \multicolumn{4}{l}{\# file MA\_example.cfg, configuration file for an MA}\\
  agentType     &=&DIET\_MASTER\_AGENT&\\
  name          &=&MA\_example        &\\
  \#traceLevel  &=&1                  &\# default\\
  \#dietPort    &=&<port>             &\# not needed\\
  \#dietHostname&=&<hostname|IP>      &\# not needed\\
  fastUse       &=&1                  &\\
  \#ldapUse     &=&0                  &\# default\\
  nwsUse        &=&1                  &\\
  nwsNameserver &=&nwshost:9001       &\\
  \#useLogService &=& 0               &\# default\\
  \#lsOutbuffersize &=& 0             &\# default\\
  \#lsFlushinterval &=& 10000           &\# default\\
 \end{tabular}
\end{center}
\rm

This configuration file is the only argument to the executable
\texttt{dietAgent}, which is installed in
\texttt{$<$install\_dir$>$/bin}. Provided
\texttt{$<$install\_dir$>$/bin} is in your PATH environment variable, run
{\footnotesize
\begin{verbatim}
~ > dietAgent MA_example.cfg

Master Agent MA_example started.
\end{verbatim}
}


\subsubsection{Launching an LA}

For such a platform, an LA configuration file could be:
\tt
\begin{center}
 \footnotesize
 \begin{tabular}{lcll}
  \multicolumn{4}{l}{\# file LA\_example.cfg, configuration file for an LA}\\
  agentType    &=&DIET\_LOCAL\_AGENT&\\
  name         &=&LA\_example       &\\
  parentName   &=&MA\_example       &\\
  \#traceLevel &=&1                 &\# default\\
  \#dietPort    &=&<port>             &\# not needed\\
  \#dietHostname&=&<hostname|IP>      &\# not needed\\
  fastUse    &=&1                 &\\
  \#ldapUse    &=&0                 &\# default\\
  nwsUse     &=&1                 &\\
  nwsNameserver&=&nwshost:9001      &\\
  \#useLogService &=& 0               &\# default\\
  \#lsOutbuffersize &=& 0             &\# default\\
  \#lsFlushinterval &=& 10000           &\# default\\
 \end{tabular}
\end{center}
\rm

This configuration file is the only argument to the executable
\texttt{dietAgent}, which is installed in
\texttt{$<$install\_dir$>$/bin}. This LA will register as a child of
MA\_example. Run {\footnotesize
\begin{verbatim}
~ > dietAgent LA_example.cfg

Local Agent LA_example started.

\end{verbatim}
}

\subsubsection{Launching a server}

For such a platform, a \sed\ configuration file could be:
\tt
\begin{center}
 \footnotesize
 \begin{tabular}{lcll}
  \multicolumn{4}{l}{\# file SeD\_example.cfg, configuration file for a SeD}\\
  parentName   &=&LA\_example        &\\
  \#traceLevel &=&1                 &\# default\\
  \#dietPort    &=&<port>             &\# not needed\\
  \#dietHostname&=&<hostname|IP>      &\# not needed\\
  fastUse    &=&1                 &\\
  ldapUse    &=&1                 &\\
  ldapBase     &=&ldaphost:9000     &\\
  ldapMask     &=&dc=LIP,dc=ens-lyon,dc=fr&\\
  nwsUse     &=&1                 &\\
  nwsNameserver&=&nwshost:9001      &\\
  \#useLogService &=& 0               &\# default\\
  \#lsOutbuffersize &=& 0             &\# default\\
  \#lsFlushinterval &=& 10000           &\# default\\
 \end{tabular}
\end{center}
\rm

The \sed\ will register as a child of LA\_example. Run the executable
that you linked with the DIET SeD library, and do not forget that the
first argument of the method call \texttt{diet\_SeD} must be the path of the
configuration file above.


\subsubsection{Launching a client}

Our client must connect to the MA\_example:
\tt
\begin{center}
 \footnotesize
 \begin{tabular}{lcll}
  \multicolumn{4}{l}{\# file client.cfg, configuration file for a client}\\
  MAName       &=&MA\_example        &\\
  \#traceLevel &=&1                 &\# default\\
 \end{tabular}
\end{center}
\rm

Run the executable that you linked with the DIET client library, and
do not forget that the first argument of the method call
\texttt{diet\_initialize} must be the path of the configuration
file above.

\section{GoDIET}
\label{sec:deployGoDIET}

GoDIET is a Java-based tool for automatic DIET deployment that
manages configuration file creation, staging of files, launch of
elements, monitoring and reporting on launch success, and process
cleanup when the DIET deployment is no longer needed~\cite{CDa05}.
The user of GoDIET describes the desired deployment in an XML file
including all needed external services (e.g. omniNames and
LogService); the desired hierarchical organization of agents and
servers is expressed directly using the hierarchical organization of
XML.  The user also defines all machines available for the
deployment, disk scratch space available at each site for storage of
configuration files, and which machines share the same disk to avoid
unecessary copies. GoDIET is extremely useful for large deployments
(e.g. more than 5 elements) and for experiments where one needs to
deploy and shut-down multiple deployments to test different
configurations. Note that debugging deployment problems when using
GoDIET can be difficult, especially if you don't fully understand
the role of each element you are launching.  If you have trouble
identifying the problem, read the rest of this chapter in full and
try launching key elements of your deployment by hand.  GoDIET is
available for download on the
web\footnote{http://graal.ens-lyon.fr/DIET/godiet.html}.

An example input XML file is shown in Figure~\ref{fig:godietXml}; see
\cite{CDa05} for a full explanation of all entries in the XML. You can
also have a look at the fully commented XML example file provided in
the GoDIET distribution under examples/commented.xml, each option is
explained. To launch GoDIET for the simple example XML file provided
in the GoDIET distribution under examples/example1.xml, run:

\begin{verbatim}
~ > java -jar GoDIET-x.x.x.jar example1.xml
XmlScanner constructor
Parsing xml file: example1.xml
GoDIET>
\end{verbatim}

GoDIET reads the XML file and then enters an interactive console mode.
In this mode you have a number of options:

\begin{verbatim}
GoDIET> help
The following commands are available:
    launch:     launch entire DIET platform
    stop:       kill entire DIET platform using kill pid
    status:     print run status of each DIET component
    history:    print history of commands executed
    help:       print this message
    exit:       exit GoDIET, do not change running
    platform.
\end{verbatim}

We will now launch this example; note that this example is intentionally very 
simple with all components running locally to provide initial familiarity 
with the GoDIET run procedure.  Deployment with GoDIET is especially useful 
when launching components on multiple remote machines.

\begin{verbatim}
GoDIET> launch
* Launching DIET platform at Wed Jul 13 09:57:03 CEST 2005

Local scratch directory ready:
        /home/hdail/tmp/scratch_godiet

** Launching element OmniNames on localHost
Writing config file omniORB4.cfg
Staging file omniORB4.cfg to localDisk
Executing element OmniNames on resource localHost
Waiting for 3 seconds after service launch

** Launching element MA_0 on localHost
Writing config file MA_0.cfg
Staging file MA_0.cfg to localDisk
Executing element MA_0 on resource localHost
Waiting for 2 seconds after launch without log service feedback

** Launching element LA_0 on localHost
Writing config file LA_0.cfg
Staging file LA_0.cfg to localDisk
Executing element LA_0 on resource localHost
Waiting for 2 seconds after launch without log service feedback

** Launching element SeD_0 on localHost
Writing config file SeD_0.cfg
Staging file SeD_0.cfg to localDisk
Executing element SeD_0 on resource localHost
Waiting for 2 seconds after launch without log service feedback
* DIET launch done at Wed Jul 13 09:57:14 CEST 2005 [time= 11.0 sec]
\end{verbatim}

The \texttt{status} command will print out the run-time status of all launched 
components.  The \texttt{LaunchState} reports whether GoDIET observed
any errors during the launch itself.  When the user requests the launch
of LogService in the input XML file, GoDIET can connect to the LogService 
after launching it to obtain the state of launched components; when
available, this state is reported in the \texttt{LogState} column.

\begin{verbatim}
GoDIET> status
Status   Element   LaunchState   LogState   Resource     PID
         OmniNames running       none       localHost    1232
         MA_0      running       none       localHost    1262
         LA_0      running       none       localHost    1296
         SeD_0     running       none       localHost    1329
\end{verbatim}

Finally, when you are done with your DIET deployment you should always run 
\texttt{stop}.  To clean-up each element, GoDIET runs a \texttt{kill}
operation on the appropriate host using the stored PID of that element.

\begin{verbatim}
GoDIET> stop

* Stopping DIET platform at Wed Jul 13 10:05:42 CEST 2005
Trying to stop element SeD_0
Trying to stop element LA_0
Trying to stop element MA_0
Trying to stop element OmniNames

* DIET platform stopped at Wed Jul 13 10:05:43 CEST 2005[time= 0.0 sec]
* Exiting GoDIET. Bye.
\end{verbatim}

\begin{figure}[p]
\input{xml_example.tex}.
\caption{Example XML input file for GoDIET.\label{fig:godietXml}}
\end{figure}







